[レポート] 生成AIを使ってファイアウォールを強化しよう #NIS375 #AWSreInforce

こんにちは！ AWS 事業本部コンサルティング部のトクヤマシュンです。

フィラデルフィアで開催されている AWS re:Inforce 2024 に参加していました。

本記事は AWS re:Inforce 2024 のセッション「Enhance your firewall protection with generative AI」のセッションレポートです。
Amazon Bedrockを使ったAWS Network Firewallの効率的な運用方法を体験するセッションでした。

セッション概要

Have you collected logs from different security services while being unsure of what to do with them? Log analysis can help organizations verify that systems are secure and any anomaly will be flagged. Reviewing logs helps you quickly identify disruptions and even mitigate security misconfiguration. In this workshop, learn how you can make use of Amazon Bedrock to mitigate network access analyzer findings through the creation of Suricata firewall, NACL, and SG rules. You must bring your laptop to participate.

時間は120分。
簡単に内容をサマリしてお伝えします。

内容サマリ

このWorkshopは大きく2つの章に分かれていました。　

• ログ解析
  • Amazon CloudWatch Logsに出力されたAWS Network Firewallのアラートログを、Amazon Bedrockを使って解析します
• Suricataルール作成
  • AWS Network FirewallのSuricataルールをAmazon Bedrockで生成します

それぞれ説明します。

ログ解析

ハンズオンの流れ

ワークショップ参加者にはそれぞれハンズオン用のアカウントが与えられます。
そのアカウントには下記のようなAWS Network Firewallを用いた環境がプロビジョニングされています。

こうした環境に対し、下記の操作を実行します。

• Private Subnet内のEC2からAlphaSOC社のNetwork Flight Simulatorを用いて不正通信のテストを実施
• アラートログのknowledge base作成
• Amazon Bedrockを用いて解析

具体的な操作をみていきます。

不正通信のテスト

Network Flight Simulatorは事前にEC2にインストール済みであるため、flightsim runコマンドを実行して不正通信のテストを行います。

Network Flight Simulatorというツールは初めて知ったのですが、DNSトンネリング、DGAトラフィック、既知のアクティブなC2宛先へのリクエスト、その他の不審なトラフィックパターンをシミュレートするテストを実行できるツールとのことです。
こうしたNW関連のセキュリティツールを検証する時に、とても役立ちそうですね。

Network Flight Simulatorを実行してから5分少し待つと、CloudWatch LogsにNetwork Firewallのログが出力されます このログは一行ずつ下記のような形式で出力されます。

こうしたログがまとまっている最新のログストリームを選択してダウンロードしておきます。

アラートログのknowledge base作成

はじめに、Amazon Bedrockで利用するために利用可能なモデルを設定します。

Amazon Bedrockのコンソール画面からModel Access > Enable specific modelsと進みます。
下記の2つのモデルのみを有効化します。

• Anthropic - Claude 3 Sonnet
• Titan Text Embeddings V2

数分まてば有効化完了となり、これらのモデルが利用可能となります。

次にアラートログをAmazon Bedrockに取り込みます。
先ほど実行したNetwork Flight Simulatorは少しの実行だったので出力されたログの量はそれほど多くなかったのですが、大量に実行してアラート検出させた時のログがハンズオン環境のS3にすでに用意されていますので、これを利用します。 (キューピー3分クッキングみたいですね)

Amazon Bedrock のコンソール画面から Knowledge Bases > Create knowledge baseと進み、名前やIAMロール、データソースに対象のS3オブジェクトなどを設定してknowledge baseを作成します。

Knowledge baseの作成が完了すれば、Syncを行います。

これで、アラートログのAmazon Bedrockへの取り込みが完了し、プロンプト経由で質問ができるようになりました。

Amazon Bedrockを用いて解析

さぁ、いよいよ解析です！

Test knowledge base パネルを開き、下記のように利用するモデルを設定してApplyをクリックすればプロンプトによる質問を実行できるようになります。

では、下記のような課題が用意されているので、ログの解析を行ないます。

Excercise1:

You want to know what is the logs about in the knowledge base. What should you be using in your prompt to get this information?

次のようなプロンプトで質問しました。

Tell me What is the logs about in the knowledge base.

回答は下記の通りでした。

The logs in the knowledge base appear to be firewall logs from an AWS firewall called "reinforce-TestFirewall" located in the us-east-1a availability zone. The logs contain information about network events detected by the firewall, including: - Alerts triggered by the firewall's intrusion detection/prevention system (IDS/IPS) rules. These alerts have a severity level and signature details. - Information about the network traffic that triggered the alerts, such as the source IP address, source port, and application protocol (e.g. TLS, HTTP).

AWS Network Firewallのログであることを正しく示せました。

Excercise2:

AWS Network Firewall alert logs provide great information about what traffic is coming into your AWS environment and how you can enhance your network firewall rules.

Task: Write a prompt that will give ou the insights to the logs.

次のようなプロンプトで質問しました。

Tell me what traffic is coming into my AWS environment and how I can enhance my network firewall rules.

回答は下記の通りでした。

Based on the search results, the reinforce-TestFirewall in the us-east-1a availability zone is allowing inbound TCP traffic from the source IP 184.105.247.196 on port 15528 to the destination IP 10.1.3.12 on port 5901. This traffic is being allowed by the firewall rule with signature "aws:alert_strict action" which has a severity level of 3.[1][2][3][4][5] To enhance the network firewall rules, you could consider blocking or restricting this inbound traffic if it is not required for legitimate purposes. You may want to review the firewall rules and signatures to ensure they align with your desired security posture and only allow necessary traffic. Regularly reviewing and updating firewall rules is recommended to maintain a strong security stance.[6][7][8][9][10]

アラートアクションで出ていたログに対して、ルール強化するためにブロックや制限を検討するよう勧めてくれていますね。

Excercise3:

The model is able to provide insights into the threats identified based on the logs ingested. For a secutiry team, it will be critical to have steps that are actionable to mitigate the threat.

Task: Write a prompt that will give you steps hat can prevent the threats identified.

次のようなプロンプトで質問しました。

Tell me the steps for the mitigating the threats identified based on the logs in the knowledge base

回答は下記の通りでした。

Based on the provided search results, which appear to be AWS Firewall logs for the "reinforce-TestFirewall" firewall in the us-east-1a availability zone, there are multiple alert events detected with a severity of 3 and signature ID 5 ("aws:alert_strict"). The logs show the source IP address 10.1.3.12 and source port 44648 triggered these alerts over the TLS protocol.[1][2][3][4][5] To mitigate the threats identified in these firewall logs, some potential steps could include: 1. Investigate the source IP 10.1.3.12 to determine if it is a legitimate or malicious IP address. If malicious, block it at the firewall or network level. 2. Review the signature details for "aws:alert_strict" signature ID 5 to understand what type of threat it is detecting, and take appropriate actions based on that (e.g. update security policies, patch vulnerabilities, etc.). 3. Monitor for any additional alerts from this source IP and signature, and escalate response if the threat persists or increases in severity. 4. Review firewall rules and policies to ensure they are properly configured to detect and prevent these types of threats. 5. Consult AWS documentation and security best practices for further guidance on interpreting firewall logs and mitigating detected threats.[6][7][8][9][10]

前半はアラートの詳細、後半はアラートに対して、下記のようなステップを提案してくれています。

1. 送信元IPアドレスを調べる
2. 検出されている脅威を把握し、適切なアクションを実施
   • セキュリティポリシーの更新、脆弱性のパッチ適用など
3. この送信元IPとシグネチャの追加アラートを監視し、脅威が継続するか重大度がました場合は対応をエスカレート
4. ファイアウォールのルールとポリシーを確認し、これらの種類の脅威を検出して防止するように適切に設定されていることを確認
5. ファイアウォール ログの解釈と検出された脅威の軽減に関する詳細なガイダンスについては、AWSドキュメントとセキュリティのベストプラクティスを参照

5はもっと早いステップでやったほうがいいんじゃないか？などは思いますが、対応方針を教えてくれました。

このように、Amazon Bedrockを使ってログ解析を行い、とるべきアクションを見出すことができました。実運用で使うにはアドバイスが少し抽象的すぎるように思いましたが、Knowledge baseの情報がログだけだったからなのかな？と思います。アラートを出しているルールについての情報も含めていれば、ルールに応じたアクションを提示してくれるのではないかな？と思いました。

以上で前半は終了です。

Suricataルール作成

前半では準備されたアラートログを解析してどのような不正通信が行われているのか、といったインサイトを得ました。

後半ではこうしたアラートログを出力するためにAWS Netowrk Firewallに追加するSuicataルールをBedrockを使って作成します。
SuricataルールがNetwork Firewallでどのように使われるかについては、Examples of stateful rules for Network Firewall をご参照ください。

ハンズオンの流れ

引き続き、同じ環境を使ってハンズオンを進めます。 今回は下記のような流れでした。

• Suricataルールに慣れる
  • ルールグループを作って検知やブロックを試してみました
  • 今回は説明割愛します
• Suricataルールのknowledge base作成
• Amazon Bedrockを用いて不正通信を検知するためのSuricataルール作成

具体的な操作をみていきます。

Suricataルールのknowledge base作成

前章ではアラートログを用いたknowledge baseを作成しましたが、今回はSuricataルールについて記載されたドキュメントをknowledge baseとして活用します。ここでは下記のドキュメントを利用しました。
Suricataユーザーガイド（現時点での最新版であるRelease 8.0.0-dev)

ドキュメントをS3に保存してデータソースとして指定する以外は先ほどと同じ作業を行い、knowledge baseを作成します。

knowledge base作成が終わればこちらもsyncを行い、準備完了です。

Amazon Bedrockを用いてSuricataルール作成

先ほどとは違い、今回は不正通信を行うためのツールは別で準備されたtestegressを使います。
おそらく今回ANFW(AWS Network Firewall)をわかりやすくテストされるために作られたツールで、EC2から次のようにメジャーな攻撃をテストするトラフィックを発生させ、ALLOWED/BLOCKEDを表示してくれるものとなっています。
初回実行時はすべてALLOWEDとなってしまっています。

では、Amazon Bedrockを用いてSuricataルールを作成します。

下記に課題とその回答の例をいくつか示します。

Excercise1:Block direct-to-IP HTTP traffic

Create a prompt to generate the Suricata rule to prevent this attack vector. Hint: The action word used should be DROP.

次のようなプロンプトで質問しました。

Tell me the example of the suricata rule using the action named DROP to drop the packets whitch communicate with ip and without FQDN over HTTP.

回答は下記の通りでした。

Based on the search results, I could not find an exact rule to drop HTTP traffic to IP addresses without domain names in Suricata. However, you can create a rule to detect and alert on such traffic. For example:[1][2] alert http any any -> any any (msg:"HTTP Request to IP Address"; flow:established,to_server; content:"/"; http_host; pcre:"/\d+\.\d+\.\d+\.\d+/"; classtype:web-application-attack; sid:1000001; rev:1;) This rule will alert when an HTTP request is made to an IP address instead of a domain name. The pcre option checks if the http_host field contains an IP address pattern. You can then use iptables to drop the traffic based on this alert.[3][4][5]

この回答で提案されたルールは下記の通りです。

alert http any any -> any any (msg:"HTTP Request to IP Address"; flow:established,to_server; content:"/"; http_host; pcre:"/\d+\.\d+\.\d+\.\d+/"; classtype:web-application-attack; sid:1000001; rev:1;)

アクションが「alert」になってしまっていますね。。。これは何度プロンプトを他のものに変えても、変わりませんでした。私のプロンプト力の問題かもしれません。

アクションを「drop」に変更したものを実際にAWS Newtork Firewallのruleに追加してみて、testegressを実行したところ、次のようにブロックされることが確認できました。

Excercise2:Block HTTP from using HTTP/TLS port 443

Attacks often send HTTP malware download requests over other ports that are likely to be open like TCP port 443. In this task, you will set up the rule needed to block HTTP traffic from using HTTP/TLS port 443.

Create the prompt to generate the Suricata rule to prevent this attack vector.

次のようなプロンプトで質問しました。

Tell me the example of the suricata rule using the action named DROP to drop the HTTP packets on HTTP/TLS port 443.

回答は下記の通りでした。

To drop HTTP traffic on port 443 using Suricata rules, you can use the following rule: drop http any any -> any 443 (msg:"Drop HTTP traffic on port 443"; sid:1000001; rev:1;) This rule will drop any HTTP traffic destined for port 443, regardless of the source IP address or destination IP address. The 'any' keyword is used to match any IP address for the source and destination.[1][2] Note that Suricata can automatically detect HTTP traffic regardless of the port it is running on. So this rule will drop HTTP traffic even if it is not running on the standard port 80. However, if you want to be more specific and only drop HTTP traffic on port 443 and not other ports, you can modify the rule as: drop http any any -> any 443 (msg:"Drop HTTP traffic on port 443"; app-layer-protocol:http; sid:1000001; rev:1;)[3][4]

この回答で提案されたルールは下記の通りです。

drop http any any -> any 443 (msg:"Drop HTTP traffic on port 443"; sid:1000001; rev:1;)

今度はアクションがdropのルールを提案してくれていますね。このルールも追加してtestegressを実行したところ、次のようにブロックされるようになったことが確認できました。

Excercise3:Block outbound FTP protocol

This method of attck shows up in modern malware/trojans(e.g. Agent Tesla) using is as C2 or data exfiltration channel. FTP also sends data in cleartext so application workloads should not have reasons to send/receive data over FTP.

Create a prompt to generate the Suricata rule to block FTP outbound traffic over port 21.

次のようなプロンプトで質問しました。

Tell me the example of the suricata rule using the action named DROP to drop the outbound packets on FTP TCP port.

回答は下記の通りでした。

To drop outbound FTP traffic on the TCP port with Suricata, you can use the following iptables rule: sudo iptables -I OUTPUT -p tcp --dport 21 -j NFQUEUE[1] This rule will send all outgoing TCP traffic destined for port 21 (the standard FTP port) to the NFQUEUE, where Suricata can inspect and potentially drop the packets based on its rules. You can then create a Suricata rule to drop this FTP traffic, such as: drop tcp any any -> any 21 (msg:"Drop outbound FTP"; flow:to_server; app-layer-protocol:ftp; classtype:policy-violation; sid:1000001; rev:1;)[2][3]

この回答で提案されたルールは下記の通りです。

drop tcp any any -> any 21 (msg:"Drop outbound FTP"; flow:to_server; app-layer-protocol:ftp; classtype:policy-violation; sid:1000001; rev:1;)

今回もアクションがdropのルールを提案してくれていますね。このルールも追加してtestegressを実行したところ、次のようにブロックされるようになったことが確認できました。

終わりに

本記事では AWS re:Inforce 2024 のセッション「Enhance your firewall protection with generative AI」のセッションレポートをお届けしました。
かなり簡単に運用にAmazon Bedrockを取り入れ、効率化・強化をすることができたのではないでしょうか？
今回ご紹介した方法は他のサービスでも応用できるかと思います。Bedrockのような生成AIを使った運用効率化の1パターンとして、ご参考いただければと思います。

本レポートがどなたかのお役に立てば幸いです。